End of life: 6/13/2027, Latest version: 26.8.0

LibreOffice Calc compiles cell formulas when opening a spreadsheet. A heap buffer overflow existed when compiling a very long formula made up of many opening tokens. The array that tracks nesting depth was allocated one element too small for that worst case, so such a formula wrote one element past its end. In fixed versions the array is sized to hold the largest possible nesting.

LibreOffice can import documents in the OOXML format (DOCX). A heap buffer overflow existed when replaying deferred parser events for a text box element. A handler object was assumed to be of one type and written to at that type's field layout, but it could be a smaller object, so the write landed past the end of the allocation. In fixed versions the type is checked before the write.

Out-of-bounds write vulnerability in The Document Foundation LibreOffice via crafted OOXML documents with mismatched encryption salt parameters.

This issue affects LibreOffice: from 26.2 before 26.2.3, from 25.8 before 25.8.7.

Last updated 21 May 2026

End of life: 11/30/2026, Latest version: 26.2.5

An Authentication Bypass vulnerability existed where the application bundled an interpreter (Python) that inherits the Transparency, Consent, and Control (TCC) permissions granted by the user to the main application bundle

By executing the bundled interpreter directly the attacker's scripts run with the application's TCC privileges

In fixed versions parent-constraints are used to allow only the main application to launch interpreter with those permissions

This issue affects LibreOffice on macOS: from 25.2 before < 25.2.4.

Am 10.12.2025 um 12:35:17 Uhr schrieb Vincent Lefevre: Under Linux X11, LibreOffice (Writer, Calc, Draw...) silently puts searched text into the PRIMARY selection when a search is active and its window gets the focus. This can yield such text to be disclosed to web sites (when one clicks with the middle button in some form) and to other applications using the same X server (without needing any action from the user). This behavior exists in various applications like browsers, when focusing the address bar (I saw that in Pale Moon). Dunno if that is related to the GTK toolkit.

The common behavior for applications is that text is only copied to primary if it is actively selected.

-- Gruß Marco

Send unsolicited bulk mail to 1765366517muell () cartoonies org

Under Linux X11, LibreOffice (Writer, Calc, Draw...) silently puts searched text into the PRIMARY selection when a search is active and its window gets the focus. This can yield such text to be disclosed to web sites (when one clicks with the middle button in some form) and to other applications using the same X server (without needing any action from the user).

A search in LibreOffice should have remained local to LibreOffice. Text entered in the search field may be private or confidential, thus it must not be disclosed anywhere else.

To reproduce:

1. Start LibreOffice Writer (or Calc, Draw...). 2. Type Ctrl-F to start a search. 3. Type some text to search (a single character is sufficient). 4. Optional: Select some text in another application, e.g. xterm. 5. Move the cursor over the LibreOffice window. With window managers that support "focus-follows-mouse" (e.g. FVWM and twm), this window gets the focus. Otherwise you need to click so that this window gets the focus.

Result: The text in the LibreOffice search field automatically becomes the new PRIMARY selection. This can be seen by pasting the PRIMARY selection somewhere else (with the middle button) or with the following script (using the xclip utility):

while true do new=$(xclip -o 2> /dev/null) if [ "x$new" != "x$old" ]; then printf "%s\n" "$new" old=$new fi sleep 1 done

which prints text from the current PRIMARY selection, as soon as it is modified.

Note: The text in the LibreOffice search field appears as selected, but this should have remained internal to LibreOffice. For instance, when I click on the address bar of Firefox, its contents get selected, but the PRIMARY selection is unchanged.

Affected LibreOffice versions (at least): 24.2.5, 24.2.6 and 25.8.3.2

In case this matters, I'm using the libreoffice Debian package under Debian/unstable.

Bug I had reported last year (I forgot about it, until I got caught again today, wondering what was happening): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080978 https://bugs.documentfoundation.org/showbug.cgi?id=162821

-- Vincent Lefèvre <vincent () vinc17 net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)

End of life: 6/12/2026, Latest version: 25.8.7

Improper Verification of Cryptographic Signature vulnerability in LibreOffice allows PDF Signature Spoofing by Improper Validation.

In the affected versions of LibreOffice a flaw in the verification code for adbe.pkcs7.sha1 signatures could cause invalid signatures to be accepted as valid

This issue affects LibreOffice: from 24.8 before < 24.8.6, from 25.2 before < 25.2.2.

An Improper Certificate Validation vulnerability in LibreOffice allowed an attacker to self sign an ODF document, with a signature untrusted by the target, then modify it to change the signature algorithm to an invalid (or unknown to LibreOffice) algorithm and LibreOffice would incorrectly present such a signature with an unknown algorithm as a valid signature issued by a trusted person

This issue affects LibreOffice: from 7.0 before 7.0.5, from 7.1 before 7.1.1.

LibreOffice supports Office URI Schemes to enable browser integration of LibreOffice with MS SharePoint server. An additional scheme 'vnd.libreoffice.command' specific to LibreOffice was added. In the affected versions of LibreOffice a link in a browser using that scheme could be constructed with an embedded inner URL that when passed to LibreOffice could call internal macros with arbitrary arguments. This issue affects LibreOffice: from 24.8 before < 24.8.5, from 25.2 before < 25.2.1.

Last updated 11 March 2025

Improper Input Validation vulnerability in The Document Foundation LibreOffice allows Windows Executable hyperlink targets to be executed unconditionally on activation.This issue affects LibreOffice: from 24.8 before < 24.8.5.

Exposure of Environmental Variables and arbitrary INI file values to an Unauthorized Actor vulnerability in The Document Foundation LibreOffice.

URLs could be constructed which expanded environmental variables or INI file values, so potentially sensitive information could be exfiltrated to a remote server on opening a document containing such links.

This issue affects LibreOffice: from 24.8 before < 24.8.4.

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in The Document Foundation LibreOffice allows Absolute Path Traversal.

An attacker can write to arbitrary locations, albeit suffixed with ".ttf", by supplying a file in a format that supports embedded font files.

This issue affects LibreOffice: from 24.8 before < 24.8.4.

After I sent the previous message, I realized that there may be more to what component these CVEs are against.

CVE-2012-0037 was against "Redland Raptor (aka libraptor) before 2.0.7, as used by OpenOffice 3.3 and 3.4 Beta, LibreOffice before 3.4.6 and 3.5.x before 3.5.1, and other products, allows user-assisted remote attackers to read arbitrary files via a crafted XML external entity (XXE) declaration and reference in an RDF document."

... and this very description explains why it scored lower - it was for specific common uses of the Raptor library. Specifying that user interaction is required was reasonable in context of needing to load a file into a desktop application.

Now that the issue was instead addressed in libxml2, the CVSS vector may be different because that library is used in many more places and ways. A relevant question (to those more familiar with this than I am) would be whether affected uses other than by Raptor likely exist (and are likely addressed by the same change in libxml2) and where/what they are. Ditto about uses of Raptor other than by those desktop office projects.

On Wed, Dec 25, 2024 at 06:04:22PM -0500, Demi Marie Obenour wrote: On Wed, Dec 25, 2024 at 07:13:21PM +0100, Solar Designer wrote: On Wed, Dec 25, 2024 at 11:52:06AM +0200, Yair Mizrahi wrote: libxml2, CVE-2024-40896, was published recently and given a "Critical" (9.1) severity by CISA. Interestingly - This vulnerability is a regression of an issue that was identified over a decade ago - CVE-2012-0037, which was given a "Medium" (6.5) severity.

Is the massive increase in CVSS over the exact same issue justified? We believe that it's inflated. I think both CVSS vectors are "buggy", and CVSS is quite poor at scoring library code vulnerabilities.

CVE-2012-0037 NIST NVD CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N CVE-2024-40896 CISA-ADP CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

The differences are whether user interaction is required or not (can't know that for library code, so have to assume either best or worst case) and what impact there is (again can't know it for library code, but these two test vectors somehow assume different impacts). Given how poor CVSS base score is for scoring library code in general, I'm afraid this issue would more "reasonably" (per CVSS spec) be scored 10.0 as AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, because such exposed usage of the library is realistic, SSRF would be a change of scope (right?), and the worst impacts of all 3 kinds are quite possible. If SSRF is a scope change, shouldn't that mean that RCE is also a scope change? It's usable for SSRF after all. That's a good point. I am no CVSS expert, but I guess the answer is no. I am also unsure whether SSRF is a scope change - maybe a CVSS "lawyer" will comment on that.

Apparently, CVSS distinguishes direct vs. secondary impact. Relevantly, looking at the examples https://www.first.org/cvss/v3.1/examples I see that while high impact on integrity usually goes along with high impact on availability, this is not always the case. In one example of I:H/A:N, the comment says "Any availability impact is secondary." It may be similar for RCE not implying scope change (secondary ability to perform SSRF) even if SSRF does (direct).

There isn't an example for SSRF on the v3.1 page above, but there is on the v4.0 page, which also includes a v3.1 vector for reference:

https://www.first.org/cvss/v4.0/examples#Server-Side-Request-Forgery-SSRF-CVE-2024-1233

In there, the v3.1 vector has scope unchanged, without explanation. In v4.0, there's no such component, but instead it's separate impact triples for vulnerable and subsequent system. In all of these cases, the impacts range from None to Low, never High. The v3.1 vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L giving a score of 7.3. But that's for SSRF that isn't a result of XXE, so maybe a reasonable vector for CVE-2024-40896 would be CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L giving a score of 8.6, or maybe lower if only some relevant uses of libxml2 would be considered.

So yeah, maybe the older vector for CVE-2012-0037 leading to a score of 6.5 is valid usage of CVSS after all. But I am not sure it's reusable when we're talking libxml2 rather than Raptor as in "office" projects.

Meanwhile, Red Hat's vector+score for CVE-2024-40896 is the same as CISA's, and Red Hat's own threat impact score for it is Critical (separate from CVSS severity name, just happens to be named the same). But none of Red Hat's products are reported affected, which suggests that a more specific analysis (than CISA's) probably was not performed. In other cases, Red Hat's scores are often lower.

Alexander

End of life: 11/30/2025, Latest version: 25.2.7.2

End of life: 6/12/2025, Latest version: 24.8.7.2

End of life: 6/12/2025, Latest version: 24.8.7.2

End of life: 11/30/2024, Latest version: 24.2.7.2

End of life: 11/30/2024, Latest version: 24.2.7.2

End of life: 6/12/2024, Latest version: 7.6.7.2

End of life: 6/12/2024, Latest version: 7.6.7.2

Improper Validation of Array Index vulnerability in the spreadsheet component of The Document Foundation LibreOffice allows an attacker to craft a spreadsheet document that will cause an array index underflow when loaded. In the affected versions of LibreOffice certain malformed spreadsheet formulas, such as AGGREGATE, could be created with less parameters passed to the formula interpreter than it expected, leading to an array index underflow, in which case there is a risk that arbitrary code could be executed. This issue affects: The Document Foundation LibreOffice 7.4 versions prior to 7.4.6; 7.5 versions prior to 7.5.1.

https://www.libreoffice.org/about-us/security/advisories/CVE-2023-0950

Improper access control in editor components of The Document Foundation LibreOffice allowed an attacker to craft a document that would cause external links to be loaded without prompt. In the affected versions of LibreOffice documents that used "floating frames" linked to external files, would load the contents of those frames without prompting the user for permission to do so. This was inconsistent with the treatment of other linked content in LibreOffice. This issue affects: The Document Foundation LibreOffice 7.4 versions prior to 7.4.7; 7.5 versions prior to 7.5.3.

https://www.libreoffice.org/about-us/security/advisories/CVE-2023-2255

End of life: 12/7/2023, Latest version: 7.5.9.2

End of life: 12/7/2023, Latest version: 7.5.9.2

End of life: 6/12/2023, Latest version: 7.4.7.2